6 ?P R S The official journal of the 
leading regional amateur 


radio digital communications 
organization of the Americas 


uarterly Report 
MAY 1998 


[4 Published by the Texas Packet Radio Society - Volume 12, Issue 4 
IN THIS ISSUE | 


TST ST STS ST ST SSSA SST ST ST STS TST ST STS STS ST SST SAS SS RTSTS ri 


President’s Report 
Tom McDermott, N5EG 


President’s Report 


As Harry Ridenour reported in the last Quarterly Report, we 
are starting to lose the wirelines that have tied TexNet 
together for many years. Midland and Lubbock connections 
Director Nomination have been lost, and we will lose the Abilene connection next. 
We are grateful for the service that has been provided by our 
carrier in the past. Without this service, we would never have 
had such a network. At this time there are no simple 
solutions to connecting the network back together. The direct 
; Au approach, using radio links would be very difficult. Initial 
Tentative TPRS Digital estimates are that it would require approximately 50 addi- 
Symposium Schedule tional nodes to do this, provided that we could secure tower 
rights in exactly the best places. The cost would be on the 
order of $75,000 - $150,000 (plus ‘free’ labor to build / test / 
install the equipment) assuming no redundant routing paths; 
Wormhole Status TPRS does not have that kind of money available. Addition- 
ally, such long hops have proven not to be very reliable 
(which is why we have tried to implement redundant routing 
where possible in much of TexNet). 


TPRS Node Assignments13 | Another approach would be to utilize the Internet to provide 
connections between the various nodes. There are several 
(Continued on page 2) 
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(Continued from page 1) 

possibilities here, but some significant technical 
work is required before this is possible. One 
approach is utilize the Cardinal card (a TexNet 
node on a PC plug-in card) and to write drivers to 
link it to a LINUX box. Then the Cardinal board 
would provide encapsulation of TexNet frames into 
IP frames. Bob Morgan is exploring this option, 
and has made great progress (see the article later 
in the QR). Another option is to utilize the proces- 
sor board being developed for the FHSS spread 
spectrum radio. A port of XINU and Comer's 
TCP/IP stack is being worked on for that board. It 
would need additional driver software to provide 
TexNet frame encapsulation. At this time, Bob 
has made such terriffic progress that the FHSS 
aproach will not need to be persued. 


However, not all of the node sites we have today 
will be able to directly access the Internet. So, it's 
likely some exiting sites will disappear, and new 
ones might arise (provided we successfully ad- 
dress the technical problems). At this time, we 
don't know how long it will take to provide solu- 
tions, but we'll keep everyone appraised. If you 
have access to a site with Internet connectivity, 
please let us know. If there are enough re- 
sponses, we'll put together a database of potential 
sites. 


Upcoming Conferences 


The Dayton Hamvention will be held next week 
(May 15-18). | attended last year for the first time. 
It's a totally amazing experience! Dayton has a 
great web site, and | encourage you to take a look 
at it. Maps, lodging, a schedule of events, and 
most importantly, a guide for first-time attendees 
(which was very helpful). Attending Dayton is like 
trying to take a sip from a fire hose. 


The Arlington Hamcom convention will be held a 
couple of week later, June 6-8, at the Arlington 
convention center. The main road from the north 
that passes by the Marriott hotel is supposed to be 
out of service, so routes from the south into the 
convention center will be your best bet. TPRS will 
have most of it's yearly activities at Hamcom. The 
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program on Saturday is great, as usual. The 
itinerary us listed elsewhere in this issue of the 
Quarterly Report. Also, the annual business meet- 
ing of TPRS will be held on Saturday, please be 
sure to stop by. It's your opportunity to nominate 
and elect directors. We try to keep the meeting 
short and to the point. In addition, drop by the 
booth either Saturday or Sunday to see what's 
happening. Saturday night we usually have a nice 
evening at a local restaurant. 


This year, TPRS has two opening for directors on 
the board (their terms expire in June of 1998). The 
expiring terms are of David Wolf, WO5H, and Joe 
Borovetz, WA5LHS. If you have an interest in 
serving on the board, or know someone who does, 
please send me email: n5eg@tapr.org. 


Other activities 


One of the nice things about my paying job is that | 
get the chance to work with top-notch research 
scientists from around the world. This last week | 
was in Boston at MIT (Massachusetts Institute of 
Technology) for a conference on recent research 
activities. MIT is well known for many innovations 
in computer networking, including X-windows and 
the X standard (UNIX graphical interface language, 
network capable). One place that | got to visit was 
the Multimedia Lab. This lab was started in the 
early 1980's, Nicholas Negroponte was the initial 
director of the lab. Negroponte has gone on to 
write several best-selling books on the future of 
computing, communications, and people. 


The purpose of the lab is to try to change how 
people interact with computers, and they are work- 
ing to break the traditional paradigm of computers 
as having keyboards and mice as input peripherals, 
and a monitor as the output peripheral. They 
design and prototype novel peripheral devices, and 
try to make the act of computing rather invisible to 
people. Although many of the actual implementa- 
tions are only of limited use, they serve to provide 
examples of technology that can be commercial- 
ized in different forms. In a University lab, the 
examples have to be cost-effective and simple to 
implement. 
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One fascinating subject was computer affectation 
(that is, how computers affect people using them). 
The lab had developed several sensors that are 
capable of detecting a few human emotions. One 
demonstration was shown where sensors were able 
to detect when the person wearing the device was 
confused or puzzled about something. As an 
increasingly-complex paragraph was read to two 
subjects, you could see the meters monitoring their 
mental state showing increasing levels of confusion 
in the subjects. Of course the idea is to extrapolate 
this to computer based learning, where the com- 
puter would be able to tell if you comprehended the 
material being taught, and could take alternative 
strategies depending on one's grasp of the subject. 
Another application would be computer self- 
defense. If the computer sensed you were frus- 
trated at trying to perform some activity, it might be 
able to automatically suggest alternatives, thus 
preventing you from breaking it in frustration! 


In another demonstration, we saw a 3-dimensional 
mouse. It was able to provide 3-d input coordi- 
nates to a computer. It used a traditional 2-d 
mouse, and an electric field sensor to detect eleva- 
tion (how high your hand was above the mouse). 
This could be used for CAD program input, for 
example, or for tracing the contour of a 3-d surface 
to describe it to the computer. However, one 
industrial member of the lab licensed similar posi- 
tioning technology to detect the type of person 
sitting in an automobile, their size, location, height, 
etc. It will use this information to determine how to 
fire an airbag in an accident, modifying the proper- 
ties for adults, children, etc., to improve the safety 
of the occupant. 


Another demonsiration was an intelligent agent. It 
is a software program that runs at the same time 
as your run a web browser. It looks at the web 
pages you are browsing, and without any interven- 
tion it determines the type of subjects you are 
interested in, the keywords of documents you fre- 
quently reference, and the links you commonly 
follow. It then starts building information about 
how you browse the web, and it starts searching 
the web links of pages that you bring up. After a 
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couple of minutes it is able to predict pretty well 
how you will browse a page, and it starts pre- 
loading those web pages before you ask for them. 
Suddenly, you notice that every web page and link 
that you click loads instantaneously (since the 
agent predicted and preloaded it before you asked 
for it). The extrapolations of this type of technol- 
ogy are rather far-reaching. 


The lab had 'wearable computing’ which are |/O 
device on clothing link to a computer. | have a 
little more difficulty seeing all the applications of 
this technology! However, it's the only time | have 
seen a large number of sewing machines in a 
research lab. 


Additionally, they are working on digital paper. In 
has the surface texture of paper, and looks like the 
page of a book, but the ink can be written and 
erased by computer. The idea is that you might 
have one book on your bookshelf, but by commu- 
nications link, it could be any book in the world, 
and would change as you wanted to look at 
different material. There was no demo of this as 
they are still working on the technology of the ink 
and the paper surface. 


The point and the relevance of all of this is that 
high-speed computer communications opens 
many opportunities in multimedia. Traditionally, 
many of us think of communications as voice, 
maybe video for some people. But really it can be 
much more, and in the next 20 years, we will no 
doubt see many of these applications transform 
into interesting and useful services. | certainly 
hope to see desktop videoconferencing in the next 
5 years. | would like to see it even earlier than that 
for selected applications, such as spread spec- 
trum radio. Members of TAPR and TPRS are 
continuing to work on the radio, but there is a lot of 
work to do before we start to see anything resem- 
bling a working prototype. However, the impor- 
tance of the technology to enabling an entire range 
of applications is of central importance. 


| will look forward to seeing everyone at Hamcom 


this year. Make plans to attend, you will be glad 
you did. -30- 
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Texas Packet Radio Society, Inc. 


TPRS was founded in 1985 and is an educational, public service, and scientific 
research non-profit corporation. Texas Packet Radio Society goals are: 


1- design and research amateur radio packet networks 
2- provide education in the area of general packet usage 


To accomplish better communications in the region, TPRS has been 
organizing statewide working groups to cover various networking topics. The 
current working groups are the Mailbox/BBS Group, TCP/IP Group, and the 
TexNet Support Group. TPRS hopes that these working groups will help 
promote information exchange in their respected areas in Texas. New working 
groups are formed as needed to provide channels for discussion and to help 
provide direction for that area of digital communications. Anyone can participate 
in a working group; TPRS membership is not required. 


TexNet 

TPRS has established a digital packet network protocol, a standard 
hardware package for the network nodes, and software modules that implement 
the TexNet network. 

The basic design philosophy of TexNet is an open, inexpensive, multi- 
resource, high speed ‘backbone’ with access through multi-connect capable local 
nodes. On the high speed side, TexNet is a 9600 baud network system. For local 
access, compatibility with the typical 2 meter AX.25, 1200 baud, AFSK/FM. 
station is the operational norm. Other baud rates and modulation techniques can 
be supported on the primary user port or secondary port. The system is totally 
compatible with both versions of the AX.25 protocol specifications for user 
connections. With these general specifications, TexNet has been designed and 
tested to enable all users to take advantage of this high speed, full protocol 
protected packet network system. 

Each node offers, in addition to TexNet access, local area digipeater service, 
2 conference bridges for full protocol protected roundtable or net operation, a full 
mult-connect, multi-user mailbox system, a local console for installation and 
maintenance setups, a debugger module for long distance and local software 
monitoring,and an interface for a weather information server for regional weather 
information, if available. 

The NCP-PC (TexNet for PC) creates a direct interface to the PC platform. 
The Z80 based PC card supports 4 channels for communications. This co- 
processor approach allows the AX.25 and TexNet-IP to run on the card without 
affecting the PC. This allows the full power of the PC to be used for network 
applications. The versatility of this board is only now being developed and 
applications are endless. 


The TexNet Network 
The Texas TexNet network system has been operational since October 
1986. When fully operational, the network reaches from the border of Mexico to 
Missouri. Use of the Texas TexNet system is open to all amateur operators. 
TPRS has been coordinating the installation of the Texas TexNet system. Further 
expansion of the system depends entirely upon the amateur community. 


INFORMATION 
TPRS is interested in spreading our information and research efforts as 
widely as possible. We want other groups involved with packet efforts to get in 
contact with us. We will provide information for those amateur packet groups 
that are interested in this system for their areas. If you would like more 
information concerning TPRS or TexNet, please drop a letter to: 


Texas Packet Radio Society, Inc. 
P. O. Box 50238 
Denton, Texas 76206-0238 


TPRS MEMBERSHIP 
TPRS membership is widespread with most members located in Texas, but 
members are located in other states and in foreign countries. Membership is 
open to any interested person. If you are interested in becoming a member and 
receiving the TPRS Quaterly, please send your name, address and call with 
membership dues of $12 per year. A membership application is available 
elsewhere in this issue. 
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2nd notice - Nominations for two TPRS Director positions open. 


The director of TPRS set the policy for TPRS, and are responsible for selecting the 
officers of TPRS. There are five directors of TPRS. Three of the terms expire in June 
of 1999, they are: Tom McDermott, N5SEG, Bob Morgan, WB5AQOH, and Jim Neely, 
WAS5LHS. Two of the director terms expire in June 1998 (at the upcoming TPRS 
general meeting), they are: Joe Borovetz, WA5VMS, and Dave Wolf, WO5H 


As of this time, we are soliciting nominations for both of these two year terms. Any 
member of TPRS can apply or be nominated for a position on the board of directors. 
Also, nominations will be accepted at the TPRS Annual Business meeting, on 
Saturday, June 6, 1998, at Hamcom in Arlington, Tx. You can mail nominations to the 
TPRS mailing address, or email them to the president, at n5eg@tapr.org 


All director nominations will be voted by the membership at the general meeting. 
Nomination for TPRS board of Directors: 


| , amember of TPRS hereby nom- 


inate the following for the position of director : 


Tentative TPRS Digital Symposium erin Me anMUALINeeN ng 
: :30- 1: rea 
Hamcon, Arlington, Tx. 1:00 - 2:00 APRS 
- Mike Heskett, WB5QLD 
Saturday, June 6, 1998 2:00 - 2:30 Linux Systems 
- Bill Reed, WDOETZ 
; a 2:30 - 3:10 TexNet & the Internet / Weather 
9:00 - 9:30 Introduction to Digital Modes - Bob Morgan, WB5AOH 
- Jim Neely, WASLHS 3:10 - 3:30 TEXNET update 
9:30 -10:30 Intro to Internet - Harry Ridenour, NOCCW 
- TBD 3:30 - 4:00 BBS update 
10:30-11:00 Intro to High-Speed Packet - Hoss Karimi, WA5ZAI 
- Greg Jones, WD5IVD 


11:00-12:00 Spread Spectrum TPRS dinner - about 6:00 PM., usually at On the 


- Greg Jones, WDSIVD, Border restaurant just east of the convention cen- 
- Tom McDermott, NSEG ter, and just south of I-30. 
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Wormhole progress 
announcement 


| have some good news to report (unless you don't 
happen to like wormholes). This afternoon, | man- 
aged to get all of the bugs and loose ends out of 
the way and | now have two stock NCPPC TexNet 
nodes connected to each other VIA an ethernet 
TCP/IP link, and they are on the actual regional 
TexNet network now. They probably will NOT be 
on the line 24 hrs/day since it is a lot of hardware 
and power drain, just when | am testing something 
or doing an endurance/statistics run. There is still 
lots of work left to be done to move the prototype to 
the internet and actually cover a few hundred miles, 
but some of the things have been done. Thanks to 
all of the folks worldwide who have written Linux 
and the various AX.25 drivers for Linux, most of 
what | did was just to string together lots of various 
off-the-shelf technology. The specific package | 
used to accomplish the job is an application (a 
daemon package) called AX25IPD, or AX.25 over 
IP. It is a plain old wormhole application to do 
almost precisely what we need. | may have to 
modify it some to take care of some specific needs 
we have, mostly related to network topology (I want 
a star topology, present revision is just point-to- 
point, stops short of multipoint). Possibly the 
author, whose name escapes me now, has an 
update to do that, but it is a fairly short routine and 
looks easily modifiable. Obviously we will also get 
some experience in dealing with ISP's, and | as- 
sume that all of them will have their peculiarities. 
There will have to be some provision to remotely 
manage and control this hardware as necessary. 

So far, | haven't tuned anything yet. It reminds me 
of the performance of the multidrop West Texas 
wireline, as it is a little sluggish and bursty, but | 
know that there are some things in the way of 
parameters that aren't set up yet, and | have 
retries, which on a short wire circuit would be 
intolerable. Most of them should be fixable directly 
as soon as | have time to chase them down. Right 
now, everything is stock as-is, from Linux to the 
TexNet code and hardware on either end. | have 
two extra computers around here, both running 
Linux, and connected by ethernet to form a real 
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short intranet, running tcp-ip. There is a TNC2, 
running KISS, plugged into the appropriate serial 
port of each Linux box. The innards of each TNC2 
(the place where we usually connect an external 
TPRS modem and UHF radio) are hardwired with a 
synch null-modem cable (sort of like the Murphy/ 
Cardnal hookup) to a modem port of the NCPPC 
TexNet node that it is associated with. One of the 
NCPPC's (AOHPMS) is connected, as always, to a 
UHF radio and is a part of TexNet. The other 
NCPPC (AOHLNk) has to get to TexNet via the 
wormhole. | ran a little traffic to Geronmo PMS 
over it, leaving a few messages to Harry, after it 
performed the most laborious chore, that of build- 
ing its own routing table to the network when it 
started up. Except that it is a little sluggish, it looks 
like any other part of TexNet. There are a few other 
major jobs left to do. One necessary item is to 
secure a few feeds to the internet, at first some 
combination of temporary and permanent loca- 
tions, and then more permanent providers. We 
have a pretty firm-sounding committment from the 
group in Midland, obviously to replace the connec- 
tivity that we recently lost when the wireline went 
away. | think that Greg may be able to provide 
some kind of a connection in Denton. | need some 
kind of a temporary drop here in Austin at some 
accessible location. For reliability, | would like to 
see something more permanent either in Austin or 
in San Antonio. Frank Aguilar in Laredo has 
expressed an interest. | have the name of a 
possible contact in Houston, of all places. Joe and 
| talk at length from time to time about various 
possibilities of finding some ISP in Okla-Ark to tie 
that portion of the network back together. Another 
job that | need to do is to make more than one 
method of connection to the network available. 
The method | am using now obviously involves an 

extra TNC2 at a site that already has a TexNet 
node on site, and that is wasteful of hardware, and 
also slows things down. | think that | can write a 
KISS driver for current NCP/NCPPC or TNC2 
TexNet code, and if so then that will eliminate the 
extra TNC2 and the extra delay and the associated 
retries. (The Linux AX25IPD program speaks 
KISS, either to a serial port, or possibly to a DRSI 
or similar Z8530-SCC packet card). The most 
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likely configuration for the Midland node seems to 
be to relocate the current Midland node from the 
wireline site to the ISP site, and install a Linux box 
on the isp's ethernet, and connect the linux box 
serial port to the NCP's serial port with a short 
cable. | think that this ought to be a fairly generic 
setup, although it won't work everywhere. Another 
possibility is to add the kiss driver to the TNC2 
TexNet 1-port node code (and when | issue revi- 
sions | normally include all platforms anyhow), and 
we could locate a linux box at some ISP, and 
include a TNC2 operating AS a 1-port TexNet node, 
complete with RF modem, either a 9600b and UHF 
radio to hit an existing part of a TexNet RF network, 
or possibly just leave the native 1200b modem in 
the TNC2 and a VHF radio for a single user port, 
possibly for a new location like Laredo, assuming 
the ISP site was suitable for RF access. This is 
somewhat of a quick and dirty method of wormhol- 
ing TexNet over the internet. It transports all layer 
2 AX.25 packets over some combination of internet 
paths. This means that all of the acks, polls, 
rejects, retries, etc are handled end-to-end inside 
TCP-IP, and that is pretty ugly when you analyze it. 


LATER ON, | am inclined to tackle the job of 
porting the layer-3 TexNet logic to Linux itself, and 
at that point, we would ship only layer 3 TexNet 
over IP, and let the error correction of IP replace 
the redundant AX25 layer-2 traffic over IP. Then, 
the NCP could be replaced by just the Linux box, 


modem, and radio. At that point, lots of other 
possible applications present themselves, besides 
just connecting TexNet together. We can provide 
all kinds of bandwidth-conscious internet services 
to radio network users, like possibly global APRS, 
weather info, extended BBS forwarding, extended 
DXC connectivity, and you get the idea. We need 
to present this to our membership for suggestions 
and input. This announcement is getting lengthy 
enough. | have several thoughts relating to topol- 
ogy and reliability (or unreliability) and | will proba- 
bly work up a separate pronouncement on that 
subject. | will probably work up some kind of a 
preliminary report to present during my timeslot at 
HamCom, while trying to stay away from vapor- 
ware type stuff as per usual. (But the things | have 
got to work today aren't vaporware). As | previously 
stated, we need to look for some friendly ISP's. 
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The more we find, the bigger we can make this 
network. We have sold NCP's all over the world, 
we may now be able to connect some of them up. 
Also note that all of what | have done here is 
directly applicable to the SS project that some of us 
are involved in. That radio under design will have 
(only) an ethernet port, and this development here 
will allow the two technologies to interconnect and 
become parts of the overall network. Maybe also 
we can run some needed SS tests if we can use SS 
to get to some of the ISP's from existing nodes. We 
also need to think about adding good bandwidth- 
friendly APPLICATIONS, that will make sense over 
packet. We need some imagination here. Unless 
we have applications, a network is unnecessay 
except as an experimental curiosity. 


This is as good a place to write down what | have 
set up and how it works, and where it appears it is 
going now, based on pland and testing to date: 


| also promised some thoughts on how we achieve 
reliability. | have made use of a software package 
called AX25IPD that runs under Linux and is avail- 
able from some places on the internet. Apparently 
it has been around awhile. RFC 1226 (I think) 
describes a procedure to encapsulate AX.25 
frames over IP, for the purpose we are talking 
about. First of all, it isn’t Telnet. That is a different 
animal entirely. Only tonight have | been able to 
sift through it and start to pin down where it fits into 
the larger TCP/IP scheme of things. Second point, 
it doesn’t use the TCP part of TCP/IP, but only uses 
IP. IP is the lower layer, roughly corresponding to 
what we might think of as layer 3, although since it 
isn’t an ISO structure the analogy isn’t exact. The 
next upper layer can be TCP, UDP, or lots of other 
things, as the design might happen to use. In this 
case, it is actually AX.25, in place of the TCP layer. 
Optionally it can use the UDP protocol as an 
intermediary (this gobbledygook means that we 
encapsulate AX.25 inside UDP, and encapsulate 
the UDP frame inside IP, and then send that, if we 
select the UDP option. If not, then we encapsulate 
AX.25 directly inside IP). | am going into this stuff 
to allow someone to sit down with an ISP and 
compare notes and see what is and isn’t mutually 
acceptable. 
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Now for some more quickie definitions: TCP is a 
connection-oriented protocol, like AX.25. Neither 
UDP or IP are connection oriented, it is sort of like 
using UI frames, although there is some more 
security to help (not guarantee) delivery. Since 
TCP is connection oriented, any program running it 
would have to have an explicit mechanism to set 
up, supervise, restart, and tear down any connec- 
tions, and since AX.25 is also connection oriented, 
it gets awfully complicated to maintain two connec- 
tion structures simultaneously to maintain one con- 
nection. Sort of like calling someone’s landline 
dialup modem, and once connected, connect to 
them with AX.25. Actually that same thing is what 
is going on with the telnet method. It can get a little 
messy. So using either direct IP, or using the 
UDP/IP option, we just specify where we want to 
go, and start throwing AX.25 frames back and 
forth, which of course set up and maintain connec- 
tions exactly as on the radio. What we have 
provided is almost like a quiet phone line between 
two TNC’s or nodes. It can be expanded to a 
conference bridge type of activity by just adding 
routes and endpoints to the tables. Unlike a confer- 


ence bridge phone line, however, there are no 
“collisions” that the AX.25 layer would see, as long 
as no collisions are occuring on the interface to the 


actual node from the Linux device. (Right now, | 
am having some of these port collisions, because | 
have some sluggish KISS parameters that | haven’t 
tuned yet. | normally don’t expect to have any 
collisions at all on such a short hardwired connec- 
tion, and the ultimate goal is to operate the KISS 
interface full duplex anyhow, so there shouldn't be 
any.) 


IP headers have a one-byte protocol ID byte, and 
the assigned number for RFC1226 AX.25 over IP is 
#93. This in addition to a 4-byte internet address to 
specify a destination computer, and the protocol ID 
serves to direct incoming internet packets to the 
AX25IPD daemon. There is no such concept as a 
port number with the IP layer by itself. When we 
add either TCP or UDP on the next layer up, (TCP 
is protocol #6, while UDP, or User Datagram Proto- 
col as it is spelled out, is protocol # 17), then the 
concept of a port number comes into play, and that 
is a double-byte number specifying 65535 possible 
ports, or potential users, within that computer at the 
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desired 4-byte internet address. If we are adding 
the optional UDP layer, then the protocol obviously 
changes from 93 to 17 for UDP, and then we have 
to assign a port. In the case of AX25IPD, it 
arbitrarily chooses port 10093. Presumably the 
choice of either raw IP, or UDP, would be made 
globally for all nodes connected together. Like- 
wise, it would be assumd that after the UDP option 
was nailed down, then the port number would also 
be universally assigned over the whole thing. Any- 
how, that is how it is now written And my gut 
preference now would be to run raw IP if we can, 
and only use UDP if for some reason we have to. | 
think that ISP preferences, firewalls, and possibly 
throughput issues might force the choice one way 
or another, and | am in unfamiliar territory here 
anyhow. Full speed ahead and see what happens. 


Now for the routing details, and this will probably 
explain what is going on. Each location (Midland, 
Denton, Tulsa, Laredo - these are the current likely 
prospects) will contain a routing table sitting on the 
Linux disk, and it is part of the config file for 
AX25IPD. This routing table contains two columns: 
destination AX.25 callsign on the left, and internet 
4-byte address on the right. If any packet ad- 
dressed to some station in the table is received on 
the KISS interface on the serial port (meaning that 
the associated TexNet node sent a packet to some 
of our destination nodes, or to some UI like ID), the 
daemon looks it up and grabs the 4-byte internet 
address and sends it there. On the receiving end, 
there isn’t any validation except checking the 
checksums. It just unwraps it and sends the AX.25 
frame out to the kiss interface, where the receiving 
NCP should grab and process it. NOTE A CRITI- 
CAL POINT HERE: 


We didnt use any AX.25 digipeaters here. 
AX25IPD on each end just ships the whole packet 
as-is. It does have a digi option, but for reasons | 
will explain later on, | can’t make use of it. All it 
does is look like a transparent wired connection, 
and move the frame unaltered. A digipeat would 
alter the frame: it would set the repeat-bit ( the 
asterisk on the TNC monitor screen), and of course 
it would demand the use of a digi address field in 
AX.25. Now in the routing table, there are as many 
specified callsigns/routes as we expect to have 
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destination callsigns that we want visible to the 
node. This includes the callsigns, and the aliases, 
and the ID broadcast destination that TexNet uses 
to start a trunk. As presently written, my version of 
AX25IPD doesn’t provide for broadcast routing. 
This is fine for connecting two locations, and totally 
worthless for a conference bridge. | am unsure at 
this point if there is a later version of the program 
that does. Some of the docs explain the broadcast 
option in the routing table, other docs leave it to a 
later revision, and | know the code to do that isn’t in 
what | have. No matter, it isn’t a terribly complex 
program. | should be able to add it if | can’t find a 
later revision that has done the work for me. So far 
this project has proceeded marvelously with off the 
shelf components throughout. It was just a lot of 
work to string it all together. 


At this point, an example of a routing table of each 
machine would probably save lots of text. Lets 
assume that we have Denton/W5NGU, Midland/ 
WB5RXA, Laredo/N5SSH, and Owasso/WA5TXX 
as the chosen nodes on the internet wormhole 
bridge. Any comparison to real people is unin- 
tended, this is hypothetical. Midland is primarily a 
DXC hub, as is Owasso, so we might expect a high 
volume of traffic to flow directly through, so we 
could afford to keep that stuff off of Denton’s NCP. 
Otherwise, we would want at this point a simple 
hub at Denton, serving Midland, Laredo, and 
Owasso. 


Next you will observe the contents of 4 routing 
tables: 


Owasso/WA5TXX/204.123.221.111 <--- this is 
Owasso’s callsign and internet 
address in 4-byte form (HYPOTHETICAL) 


W5NGU 204.123.221.222 


DENTON 204.123.221.222 

signs support all SSIDs if not shown WB5RXA 
204.123.221.133 <--- these are destina- 
tion addresses 


MIDLND 204.123.221.133 ID * <--- conceptual 
broadcast address: all members. 
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Midland/WB5RXA/204.123.221.133 <--- ditto 
for Midland and other nodes. 


WASTXX 204.123.221.111 


OWASSO 204.123.221.111 
W5NGU 204.123.221.222 
DENTON 204.123.221.222 
ID * 


Denton/W5NGU/204. 123.221.222 


WASTXX 204.123.221.111 


OWASSO 204.123.221.111 
WB5RXA 204.123.221.133 
MIDLND 204.123.221.133 
N5SSH 204.123.224.144 
LAREDO 204.123.224.144 
ID * 


Laredo/N5SSH/204.123.224.144 
only one neighbor in this example. 


W5NGU 204.123.221.222 


<--- Laredo has 


DENTON 204.123.221.222 


ID 204.123.221.222 
broadcast here, just route. 


<--- Don’t need a 


Hope this makes sense, if you have the time to sit 
down and trace it out. Note that we have to inspect 
the whole thing to ensure that we have accounted 
for all reverse routes and all ID broadcasts. TexNet 
will NOT set up a trunk to some other node if it 
can’t hear its Ul announces to ID that are sent at 8 
min intervals. Note that ALSO, we have to set up 
the routing inside TexNet so that Denton shows 
OWASSO, MIDLAND and LAREDO as neighbors, 
set up Owasso to show DENTON and MIDLAND as 
neighbors, set up MIDLAND to show OWASSO 
and DENTON as neighbors, and finally set up 
LAREDO to show DENTON as its only neighbor - 
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IN ADDITION to any other nodes that these nodes 
have as RF path neighbors. We do that on a 
port-by-port basis, in case we want to lock out 
OWASSO and MIDLAND as RF neighbors in case 
one of them consistently heard the other one during 
routine freakish band openings. Don't laugh, 
MOODY is locked out of most nodes in Texas and 
southern Oklahoma now, since it is on a TV tower. 
Also there is a TexNet limit of a total of 10 neighbor 
nodes at present. 


There is a similar limitation of table size in 
AX25IPD. | mentioned no digipeaters a little while 
ago. | don’t want to rewrite half the innards of 
TexNet layer 2 code. Not quite, but the trunk 
startup routines don’t provide for a trunk path to 
specify an intermediate digi address, whether real 
or virtual, it still takes another address slot, and 
that stuff is hardcoded and | don’t want to mess 
with it. | HAVE thought about that possibility for a 
very long time, roughly from the beginnings of 
TexNet when | thought about the possibility of 
trunking it, for instance via an OSCAR pacsat. 
What this means is that we can’t use any interme- 
diate devices to feet a TexNet trunk through that 
aren't 100% transparent. Joe and | have kicked 
around the idea of the nodestack at ft gibsn, and 
from this point of view alone, it gets ruled out. It 
also MAY get ruled out from a round-trip time 
standpoint, as | will explain next: 


We are encapsulating AX25 inside IP and shoving 


it over the internet. >From what | am given to 
understand, sometimes raw IP and UDP might get 
sent a little faster from end to end than TCP. | 
don’t know if it is signigicant or not. Anyhow, some 
parts of the internet are pretty fast indeed, and 
some parts can be pretty slow, and of course it is 
dynamic. | expect that the times that we want 
TexNet to run fast during the usual evening hours 
when folks are in the shack may for the same 
reason be slower on the internet when everybody is 
banging on the web. Anyhow, recognize that we 
are transporting ALL of AX25 over the internet, not 
just data frames but acks, polls, retries, rejects, 
supervisories, and Ul’s and the like, and the AX25 
timing will want to work end-to-end to supervise the 
AX25 connection from Midland to Owasso, if that is 
how we happen to route it. Obviously, the timing 
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parameters we set into each TexNet node have to 
allow for all of this to normally happen at whatever 
speed it happens at. There is only one timing 
parameter set for each node’s internet port, so 
Midland for example has to allow for the worst case 
timing of a round trip to/from both Denton and 
Owasso. Likewise, Denton has to allow for worst 
case to all the others. If it is set too short, then 
nodes start generating retries. NOTE that this 
should otherwise be a collisionless circuit, UNLIKE 
the old west Texas wireline, which was about 75% 
or more collisions and occasional data transfer. It 
is collisionless because each Linux box will juggle 
only one frame at a time on each interface, it can’t 
generates a collision if it only handles one packet at 
a time. Of course, there ARE higher speed colli- 
sions on the ethernet al the time, but there is 
another layer supervising that and acting to guar- 
antee some delivery there. As far as | understand 
it, it should NOT be a common occurance for IP or 
UDP to lose too many packets. TCP of course 
(which we are NOT using here) GUARANTEES 
delivery, or a disconnect. SO, we set the timing to 
a relaxed set of parameters that hopefully won't 
cause AX.25 to retry much, and that is as much 
throughput as we can get. It is totally dependant 
on the speed of the internet. If we get some good 
ISP’s on some T1’s or the like, and connect to them 
with ethernets inside their offices, we ought to do 
pretty good, and | expect that we ought to have 
superior performance to the old W Tex wireline, 
just because it will be handling more data and less 
polls and collisions. Anyhow it ought to make for a 
good experiment. One note | may have glossed 
over about KISS: Not all of you have read what | 
have in mind. My test on the bench just used a 
plain old stock TNC2 (mfj1270) running plain old 
tapr KISS, and | tied that back to back to unmodi- 
fied TexNet NCP modem ports, using a null mo- 
dem lashup between the SIO IC’s. That is only the 
first test to use unmodified and proven methods to 
keep the testing manageable. | will have to sit 
down and write a KISS driver to include in the 
TexNet EPROM that will be needed in these af- 
fected nodes, whether they are implemented as 
NCP’s or TNC2’s. That will eliminate the intermedi- 
ate hassle, expense, and time delays of the extra 
KISS TNC. In most cases the TexNet node of 
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whatever variety will connect its async or “console” 
port to the desired serial port of the linux box, and 
that will be a 3-wire cable running 9600b async, 
and handling the KISS frames that AX25IPD ex- 
pects. If necessary to prevent surge damage 
during lightning strikes, it can be optoisolated. We 
do that with several nodes now. The main point 
here is that the target configuration is to be a 
TexNet node serial port connected to a Linux router 
serial port with a short cable, and that an EPROM 
change will be needed to each of these nodes. At 
the present time, the contents of that proposed 
EPROM is good ole VAPORWARE, until | write it. 
Probably, at least in the NCP platform, codespace 
will dictate that the CONSOLE program will disap- 
pear. It is in theory possible to retain it on the 
TNC2 which has more room in the EPROM, and 
allow a dual functionality, but | really can’t see 
going to the trouble to provide the switching func- 
tionality. We manage to get along without it rathar 
nicely on dualport TNC2 nodes. (At least on Moody 
anyhow, there isn’t anyone up on the TV tower with 
a dumb terminal, and | really haven't missed it 
much on the test bench either). 


As for reliability: The old hardwired microwave 
circuits we used to use were pretty decent, and of 
course, some microwave does occasionally drop 
out with propagation or storms. All of them have 
been changed over to fiber (even in W Texas while 
it lasted), and these things ought to almost never 
fail. That stuff JUST AINT SWITCHED, so there is 
nothing to overload when things get rough. Now 
the public telephone system in general, and cellular 
in particular, is of course switched, and when THAT 
stuff gets overloaded in all sorts of disasters, that is 
when HAMS are expected to go to work and earn 
their spectrum. It will be somewhat similar for the 
internet in general. It is a bunch of leased and 
pretty reliable circuits in most cases, connecting 
LOTS of routers, which of course are traffic switch- 
ing devices, among other things. | don’t know if it 
has any real enforced standards of reliability, which 
at least the POTS has in theory. So far, it isn’t 
quite considered an essential public utility that is 
expected to be pretty foolproof, despite customer 
expectations that their money they spend on ser- 
vice will buy them some reliability. Ever hear of 
CATV service?? (oxymoron). Where | am heading 
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with all of this is that | don’t expect the internet to 
be real reliable. We HAVE to compensate some- 
how. WE still have some donated leased wirelines, 
and of course we have some RFF paths too. Some 
of them are pretty decent, others are pretty fair 
weather. WE need to design a network that is laid 
out in some sensible manner with some alternate 
capabilities. TexNet will function with alternate 
routes, but the re-routing process is MANUAL. 
Harry or | have to sit down and reload routing 
tables node by node to take advantage of it, and 
this happens within a few HOURS of when we 
become aware of it. It isn’t automatic, but then it 
normally doesn’t take days or weeks, or require site 
trips except to fix a failed site. We HAVE changed 
a FEW eproms over the years to add some alter- 
nate routes, but it is pretty infrequent, and most of 
that is behind us now. ONE thing that the internet 
wormholes will add to this is additional things to 
manage: Linux routers (The route tables | showed 
examples of above, along with their occasional 
breakdowns), and also some ISP public relations to 
keep things humming along, and we presently don’t 
do that. If a wireline gives trouble, Harry calls them 
the next day (1 day delay to see if it is a permanent 
failure needing a gratis service order), and it usu- 
ally gets fixed in a day or so. Remember, its free 
gratis service... Linux itself IS a pretty solid OS. 
Unlike anything that Billy Gates sells, this stuff 
doesn’t crash. TexNet nodes have run continu- 
ously in excess of 2 years in between service calls 
without rebooting. If the chosen PC HARDWARE 
can hold up this long, it is likely that the Linux 
nodes probably can stay booted for at least several 
months at atime. | have been playing with Linux 
since about December or so, | have yet to crash 
one with good hardware to where | couldn’ still get 
the keyboard to respond and shut it down politely. 
| bought a brand new Compaq laptop/W95 last 
month on Tax Day, and | think | locked it up just 
running program installs twice the first day or so. 
That is about the normal difference in s/w reliability. 
The last factor involves the PC hardware itself. | 
suspect that we will probably be running some 
used equipment, at least to start with. That isn’t 
automatically BAD, but it does raise some con- 
cerns about power supply aging, fans and environ- 
ment, and also about stable power. Linux falls into 
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the same category as Win95 and things running 
SmartDrive cached write, in that it must go through 
a safe shutdown procedure, or you will corrupt the 
file system because of delayed writes to disk that 
get chopped off during unplanned shutdowns, re- 
sets, or POWER FAILS. | would like to see these 
devices on stable, if not UPS power. If they DO go 
down unexpectedly, they may choose NOT to come 
back up without manual intervention, and that 
means someone knowledgeable of Linux file sys- 
tem rescue procedures has to go to the site and 
bring it back up. Otherwise, | hope we will be able 
to manage things remotely, and | am thinking 
about how to set up a procedure for remotely 
managing the Linux part of the route tables that 
won't invite too many hackers from the dark parts 
of the internet jungle. THE MOST EFFECTIVE 
method of providing some reliability in the internet 
wormhole world appears to me to be redundant 
paths through several nodes on the internet, and 
some wireline of RF bypass routes where we can 
get them. Obviously, if we lose the Laredo ISP, we 
lose Laredo. If we lose the Denton ISP, and we 
have an alternate ISP in Austin or San Antonio, 


which | sure want badly, we would only lose Den- 
ton, and then only the ISP feeds. If the NCP stayed 
up, hopefully we could feed everything out of an 


alternate node down here, a_ fter manually re- 
routing things as we do now, and Denton would 
stay up. Think about the following: WE lost 
Midland, and Lubbock, because the wireline com- 
pany went out of the particular end of the business 
we were getting free gratis. HAD we already 
implemented this scheme, and there was too much 
work standing in the way for it to happen timely like 
we wanted, we would have just re-routed it, and the 
whole Iss of service to Midland would have been a 
real non-event. AS it is, it didn’t happen totally by 
our schedule, so we lost service for hopefully no 
more than 3-4 months. Probably it would have 
happened this way anyhow, because we are on 
pretty limited resources, and we just don’t have the 
wherewithall to implement all the redundancy we 
would like. That is just human nature, when it 
comes to managing backup systems. | saw it 
happen all the time to various backup and startup 
subsystems in 18 years around a multimillion dollar 
powerplant. If it isn’t needed to run with 24/7 
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continuously, it just isn’t getting attention when it 
needs fixed until it kills you. It isn’t just resources, 
it is just human nature to give less than desired 
attention to redundant sytems, and it isn’t only 
hams on a budget. 


| apologize for the length. | had several things to 
set down in front of us as we enter this next chapter 
in the life of TexNet. One of them is to get 
everybody started thinking along common lines, so 
that we have a few less dissappointments when we 
approach ISP’s with our dreams, and another was 
a promised plan of how we achieve reliability. So 
here it is. It is getting too late to go any farther for 
ow. 


| am sending this stuff to the hognet reflector to be 
seen by those that need to look at it in Okla/Ark, 
and also am copying the various folks down here in 
Texas, including Harry and Tom, and also the 
Midland and Laredo prospects, as it will give them 
similar info that | don’t want to retype. And also 
Greg. 


73 de Bob WB5AOH 
Austin Texas 
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TPRS Node Assigments 
Official Publication: June, 1995 
Subject to Corrections/Additions/Deletions. 


= ACTIVE/COMPLETED 
ACTIVE/TEST 
= PENDING 


User 
Nr Status City/Town Alias Call Port Remarks 
Dallas TEXNET WR5C 145.05 PMS 
Richardson TESTBED W9DDD None R&D 
Richardson RICH W9DDD None R&D 
Murphy MURPHY NSEG 145.09 
Ft. Worth NWS N5HCO None Weather PMS 


Beorne BEORNE N5VUO 145.01 (Bridged w/BN 
Geronimo GERONMO WB5SNSN_ 145.07 PMS (AKA GER 
Austin AUSTIN WASLHS 145.07 

Austin NQ90 Bryan Stroud Test Node 

San Antonio ALAMO NOCCW 145.09/223.44 

San Antonio SALAMO WA2MCT Interface to SNS/NO USER PORT 
Denton DENTON W5SNGU 145.03 

Lubbock LUBBOCK W5ERO 145.05 

Midland MIDLAND WB5SRXA 145.05 

Greenville GREENVL WB5IZL 145.07 

Midland MAFDXC WF5E 223.58 DXCluster port 2 


OAAITAUHAWNE 


1x KKM KKM XM HX XO 


Rockport ROCPRT N5JKH 144.99/PORT 2 446.1 
C. Christi CORPUS N5XCH 145.05 INTERFACE TO SNS 
Pettus PETTUS KA5SBWL 147.56 

Corpus ESTES KB5GD None Test Node 
Lubbock LBBDXC KA5EJX DXCLUSTER 

Austin AUSDXC WB5VZL 144.99 

Corpus Ch CCSU N5SAHD TEXT Node 

Victoria VCTRIA W5DSC 145.01 

Alice ALICE K5DYY 145.07 

Amarillo AMARILO WD5ILA 145.05 

Abilene ABILENE WBSEKW 145.05 


5 
5 
5 
3 
Austin NQ90 Bryan Stroud Test Node 
4. 
5: 
Te< 


ix x xX 


xxx x UK XM 


Houston HOUSTON WD5HJP UNKN Due 
Pearland PEARL UNKN UNKN Due 
Rosenburg ROSBRG UNKN UNKN Due 
San Antonio SANTEX WB5SFNZ 223.58 

Hempstead HMPSTD Due 


tax tO tO tD 


Kingsville TAMUK W5ZD 144.91 (aka KINGVL) 
Bryan/CollStn SBRAZOS KF5LN 145.05/446.10 Port 0 (PENDING 
RE-INSTALLATION) 
Bryan/CollStn NBRAZOS KG5ZD 446.1 (See Nr 43) 

Fannin County FANNIN WB5RDD 145.05 

Sherman SHERMAN WBSCVR 144.93 

South Dallas SDALLAS KF5RN 
Waco WACO WD5KAL 145.09 
Falfurrias FALFUR WB5FRO None 


ux 
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Mercedes VALLEY NASC 144.60 DxXCluster port 2 

San Isidro ISIDRO K5RAV None 

Brownsville BROWX K5RAV-? NWS node 25.54.57N 97.25.08W 
Fort Worth FTWORTH N5AUX 144.99 

AOHTST AUSTIN WB5AOH NONE R&D AUSTIN 

Murphy CARDNAL WA6ROC None R&D/PMS/NMS/NETCON 


xHSx UX 


(100-150) Reserved for TexLink Node Usage 
Floresville LORES WD5DOE None 


King Mountain I WB5YHC 145.05 
Alpine I WASROE 145.05 
Refugio WB5OLT None 

San Angelo I WASJSN 145.05 


PLAINVIEW ] KCS5ALN 145.05 


Reserved -— WB5DDP 
Reserved -— WB5DDP 


Moody MOODY W5ZDN 


(151-249) Reserved for Non-Texas Node Usage 


Ft Gibson OK FTGIBSN N5GIT 145.01 
Muskogee OK MKOTST WASVMS 446.5 PMS 
Muskogee OK MUSKOGE W5EJK 145.09 


Lincoln AR FAYETVL K5VR 14 
Clayton OK CLAYTON W5CUQ 145. 
Ft Smith AR FTSMITH W5ANR 144. 


Tulsa OK TULWX NSWX NWS Server 
Okemah OK OKEMAH WBSHLR 
Choctaw OK CHOCTAW AB5H 


Garfield AR GARFLD WB2ROC 
Aurora Missouri OARSMO KOSQS 
Mt Magazine AR MAGAZIN KF5XB 
Russellville RSLVL WB5BHS 
Little Rock AR LROCK WB5SQK 144.97 PORT 2 446.50(FUTUR 
Little Rock AR LRTS KA5SQK TEST Node 


(250-255) Network Reserve 


If you are a TexNet node opearator/owner and have a correction to 
make to the list, advise to 

NOCCW@K3WGF.#STX.TX.USA.NOAM, or leave a message for 

NOCCW on the NDALLAS PMS of TexNet. 
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TPRS Membership Application 


Name Callsign 
Address 

Apt. or Mailstop 

City/State 

Zip E-mail address 


Evening Phone (_) Work Phone (__) 


Membership is $12 per year. How many years are you paying for? 


New Member Renewal 


Make check payable to: Texas Packet Radio Society 


—-—----------Y 


ATIN: 


Membership Texas Packet Radio Society 


P.O. Box 50238 
Denton, Texas 76206-0238 


Texas Packet Radio Society, Inc. 


Be sure to visit the TPRS web page: 
http://www.tprs.org 
for the latest information on TPRS 
activities. 


Directors 


Nomination 
F A current listing of Packet nodes, 
orm frequencies, and networks is located in the 
Inside North American Digital Systems 
Directory (NADSD) on-line at: 
http://www.tapr.org/directory/index.html 
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Texas Packet Radio Society 
P.O. Box 50238 
Denton, Texas 76206-0238 


ADDRESS CORRECTION REQUESTED 


To: 


